Chip 1998 September

home *** CD-ROM | disk | FTP | other *** search

/ Chip 1998 September / CHIP Eylül 1998.iso / Slackwar / docs / Security-HOWTO < prev next >

Wrap

Text File | 1997-03-05 | 53.4 KB | 1,205 lines

Linux Security HOWTO Kevin Fenzi, kevin@scrye.com v0.9.5, 1 March 1998 This document is a general overview of security issues that face the administrator of linux systems. It covers general security philosophy and a number of specific examples of how to better secure your linux system from intruders. Also included are pointers to security related material and programs. NOTE: This is a beta version of this document. Improvements, constructive criticism, additions and corrections are gratefully excepted. Due to my despam filter, you will need to mail me to get a despam key to mail me. Sorry for the trouble. To avoid this make sure you have "linux", "security" or "HOWTO" in the subject line of your mail. 1. Introduction This document covers some of the main security issues that affect linux security. General philosophy and net born resources are discussed. A number of other HOWTO documents overlap with security issues, and those have been pointed to wherever appropriate. This document is NOT meant to be a up to date exploits document. Large numbers of new exploits happen all the time. This document will tell you where to look for such up to date information, and some general methods to prevent such exploits from taking place. 1.1. New versions of this document New versions of this document will be periodically posted to comp.os.linux.answers. They will also be added to the various anonymous FTP sites who archive such information, including: ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO In addition, you should generally be able to find this document on the Linux Worldwide Web home page via: http://sunsite.unc.edu/mdw/linux.html Finally, the very latest version of this document should also be available in various formats from: http://scrye.com/~kevin/lsh/ 1.2. Feedback All comments, error reports, additional information and criticism of all sorts should be directed to: kevin@scrye.com NOTE: I use the despam filter to filter all my mail. This means that if you are not known to me, your mail will bounce with a notice to re- send with a provided "key" in the subject. I regret the trouble this causes, but since I get 20-30 spam mails a day, I have to do something. Please re-send your message with the "key" in the subject and I will read your mail. You can also avoid this step by making sure you put "linux" "security" or "HOWTO" in the subject of your mail. http://scrye.com/~kevin/ 1.3. Disclaimer No liability for the contents of this documents can be accepted. Use the concepts, examples and other content at your own risk. Additionally, this is an early version, with many possibilities for inaccuracies and errors. A number of the examples and descriptions use the RedHat(tm) package layout and system setup. Your mileage may vary. As far as I know, only programs that under certain terms may be used or evaluated for personal purposes will be described. Most of the programs will be available complete with source under GNU-like terms. 1.4. Copyright information This document is copyrighted (c)1998 Kevin Fenzi and distributed under the following terms: ╖ Linux HOWTO documents may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions. ╖ All translations, derivative works, or aggregate works incorporating any Linux HOWTO documents must be covered under this copyright notice. That is, you may not produce a derivative work from a HOWTO and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the Linux HOWTO coordinator at the address given below. ╖ If you have questions, please contact Greg Hankins, the Linux HOWTO coordinator, at gregh@sunsite.unc.edu Finger for phone number and snail mail address. 2. Overview This document will attempt to explain some procedures and commonly used software to help your linux system be more secure. The first thing to keep in mind is that there is never any such thing as a "completely" secure computer system. All you can do is make it increasingly difficult for someone to compromise your system. For the average home linux user, not much is required to keep the causal cracker at bay. For high profile linux users (banks, telecommunications companies, etc) much more work is required. Another factor to take into account is that the more you increase your system security, the more intrusive your security becomes. You need to decide where in this balancing act your system is still usable and yet secure for your purposes. For instance, you could require everyone dialing into your system to use a call back modem to call them back at their home number. This is more secure, but if someone is not at home, it makes it difficult for them to login. You could also setup your linux system with no network or connection to the Internet, but this makes it harder to surf the web. If you are a large to medium sized site, you should establish a "Security Policy" stating how much security is required by your site and what auditing is in place to check it. This document has been segregated into several sections. They cover several broad kinds of security issues. The first, physical security, covers how you need to protect your physical machine from tampering. The second describes how to protect your system from tampering by local users. The third, network security, describes how to better secure your linux system from network attacks. The next discusses what to do when you detect a system compromise in progress or detect one that has recently happened. Then links to other security resources are enumerated, and finally a few closing words. The two main points to realize when reading this document are: ╖ Be aware of your system. Check system logs such as /var/log/messages and keep an eye on your system, and ╖ Two, keep your system up to date by making sure you have installed the current versions of software and have upgraded per security alerts. Just doing this will help make your system markedly more secure. 3. Physical Security The first "layer" of security you need to take into account is the physical security of your computer systems. Who has direct physical access to your machine? Should they? Can you protect your machine from their tampering? Should you? How much physical security you need on your system is very dependent on your situation, and/or budget. If you are a home user, you probably don't need a lot (although you might need to protect your machine from tampering by children or annoying relatives). If you are in a Lab environment, you need considerably more, but users will still need to be able to get work done on the machines. Many of the following sections will help out. If you are in a Office, you may or may not need to secure your machine off hours or while you are away. At some companies, leaving your console unsecured is a termination offense. Obvious physical security methods such as locks on doors, cables, locked cabinets, and video survailance are all a good idea, but beyond the scope of this document. :) 3.1. Computer locks Many more modern pc cases include a "locking" feature. Usually this will be a socket on the front of the case that allows you to turn an included key to a locked or unlocked position. Case locks can help prevent someone from stealing your pc, or opening up the case and directly manipulating/stealing your hardware. They can also sometimes prevent someone from rebooting your computer on their own floppy or other hardware. These case locks do different things according to the support in the motherboard and how the case is constructed. On many pc's they make it so you have to break the case to get the case open. On some others they make it so that it will not let you plug in new keyboards and mice. Check your motherboard or case instructions for more information. This can sometimes be a very useful feature, even though the locks are usually very low quality and can easily be defeated by attackers with locksmithing. Some cases (most notably sparcs and macs) have a dongle on the back that if you put a cable through attackers would have to cut the cable or break the case to get into it. Just putting a padlock or combo lock through these can be a good deterrent to someone stealing your machine. 3.2. BIOS Security The BIOS is the lowest level of software that configures or manipulates your x86 based hardware. LILO and other linux boot methods access the BIOS to determine how to boot up your linux machine. Other hardware that linux runs on has similar software (OpenFirmware on macs and new suns, sun boot prom, etc...). You can use your BIOS to prevent attackers from rebooting your machine and manipulating your linux system. Under linux/x86 many pc bioses let you set a boot password. This doesn't provide all that much security (bios can be reset, or removed if someone can get into the case), but might be a good deterant (ie it will take time and leave traces of tampering). Many x86 bioses also allow you to specify various other good security settings. Check your bios manual or look at it the next time you boot up. Some examples are: disallow booting from floppy drives and passwords to access some bios features. On Linux/Sparc, your SPARC eeprom can be set to require a boot-up password. This might slow attackers down. NOTE: If you have a server machine, and you setup a boot password, your machine will not boot up unattended. Keep in mind that you will need to come in and supply the password in the even of a power failure. ;( 3.3. Boot loader Security The various linux boot loaders also can have a boot password set. Using lilo take a look at the "restricted" and "password" settings. "password" allows you to set a bootup password. "restricted" will let the machine boot _unless_ someone specifies options at the lilo: prompt (like 'single'). Keep in mind when setting all these passwords that you need to remember them. :) Also remember that these passwords will mearly slow the determined attacker. If anyone has security related information from a different boot loader, I would love to hear it. (grub, silo, milo, linload, etc). NOTE: If you have a server machine, and you setup a boot password, your machine will not boot up unattended. Keep in mind that you will need to come in and supply the password in the even of a power failure. ;( 3.4. xlock and vlock If you wander away from your machine from time to time, it is nice to be able to "lock" your console so that no one tampers with or looks at your work. Two programs that do this are: xlock and vlock. Xlock is a X display locker. It should be included in any linux distributions that support X. Check out the man page for it for more options, but in general you can run xlock from any xterm on your console and it will lock the display and require your password to unlock. vlock is a simple little program that allows you to lock some or all of the virtual consoles on your linux box. You can lock just the one you are working in or all of them. If you just lock one, others can come in and use the console, they will just not be able to use your vty until you unlock it. vlock ships with redhat linux, but your mileage may vary. Of course locking your console will prevent someone from tampering with your work, but does not prevent them from rebooting your machine or otherwise disrupting your work. 3.5. Detecting Physical Security compromises. The first thing to always note is when your machine was rebooted. Since linux is a robust and stable OS, the only times your machine should reboot is when YOU take it down for OS upgrades, hardware swapping, or the like. If your machine has rebooted without you doing it, a trouble light should go on. Many of the ways that your machine can be compromised require the intruder to reboot or power off your machine. Check for signs of tampering on the case and computer area. Although many intruders clean traces of their presence out of logs, it's a good idea to check through them all and note any discrepancy. Some things to check for in your logs: ╖ Short or incomplete logs. ╖ Logs containing strange timestamps. ╖ Logs with incorrect permissions or ownership. ╖ Records of reboots or restarting of services. ╖ missing logs. ╖ su entries or logins from strange places. Where to look for your log file will depend on your distribution. In the standard redhat setup, you will want to look in /var/log/ and check messages, mail.log, and others. You might also want to configure your log-rotating script or daemon to keep logs around longer so you have time to examine them. Take a look at the 'logrotate' package un recent redhat distributions. Other distributions likely have a similar process. 4. Local Security The next thing to take a look at is the security in your system against attacks from local users. Did I just say _local_ users? yes. Getting access to a local user is one of the first things that system intruders attempt. With lax local security, they can then "upgrade" their normal user access to root access using a variety of bugs and poorly setup local services. If you make sure your local security is tight, then the intruder will have another hurdle to jump. Local users can also cause a lot of havoc with your system even (especially) if they really are who they say they are. Providing accounts to people you don't know or have no contact information for is a very bad idea. Before changing permissions on any system files, make sure you understand what you are doing. Never change permissions on a file because it seems like the easy way to get things working. Always determine why the file has that permission before changing it. 4.1. Creating new accounts You should make sure and provide user accounts with only the minimal requirements for the task. If you provide your son (age 10) with an account, you might want them to only have access to a word processor or drawing program, but be unable to rm everything. Several good rules of thumb when allowing other people legitimate access to your linux machine: ╖ Give them the minimal amount of privileges they need. ╖ Be aware when/where they login from, or should be logging in from. ╖ Make sure and remove their account when they no longer need the access. Many local user accounts that are used in security compromises are ones that have not been used in months or years. Since no one is using them they provide the ideal attack vehicle. 4.2. File Permissions It's important to insure that your system files are not open for casual editing by users and groups who shouldn't be doing such system maintance. A quick explanation of unix permissions: Ownership - Which user(s) and group(s) retain(s) control of the permission settings of the node and parent of the node Permissions - Bits capable of being set or reset to allow certain types of access to it. Read: ╖ To be able to view contents of a file ╖ To be able to read a directory Write: ╖ To be able to add to or change a file ╖ To be able to delete or move files in a directory Execute: ╖ To be able to run a binary program ╖ To be able to search in a directory You - The owner of the file Group - The group you belong to Everyone - Anyone on the system Examples: -rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin 1st bit - directory? (no) 2nd bit - read by owner? (yes, by kevin) 3rd bit - write by owner? (yes, by kevin) 4th bit - execute by owner? (no) 5th bit - read by group? (yes, by users) 6th bit - write by group? (no) 7th bit - execute by group? (no) 8th bit - read by everyone? (yes, by everyone) 9th bit - write by everyone? (no) 10th bit - execute by everyone? (no) drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/ 1st bit - directory? (yes, it contains many files) 2nd bit - read by owner? (yes, by kevin) 3rd bit - write by owner? (yes, by kevin) 4th bit - execute by owner? (yes, by kevin) 5th bit - read by group? (yes, by users 6th bit - write by group? (no) 7th bit - execute by group? (yes, by users) 8th bit - read by everyone? (yes, by everyone) 9th bit - write by everyone? (no) 10th bit - execute by everyone? (yes, by everyone) System configuration files (usually in /etc) are usually mode 644 (-rw-r--r--), and owned by root. Depending on your sites security requirements, you might adjust this. Never leave any system files writable by a group or everyone. 4.3. Root security Another common local user attacker is the admin of your linux box. yes, you! ;) Remember that you should only use the root account for very short specific tasks and should mostly run as a normal user. Running as root all the time is a very very very bad idea. Just use su or sudo to do those tasks you need to do. Several tricks to avoid messing up your own box as root: ╖ When doing some complex command, try running it first in a non destructive way...especially commands that use globbing: ie, you are going to do a "rm foo*.bak", instead, first do: "ls foo*.bak" and make sure you are going to delete the files you think you are. Using echo in place of destructive commands also sometimes works. ╖ Some people find it helpfull to do a "touch /-i" on their systems. This will make commands like: "rm -rf *" ask you if you really want to delete all the files. (It does this by your shell resolving the "-i" file first, and treating it as the -i option to rm.) This will not help with rm statements with no * in them. ;( ╖ Only become root to do single specific tasks. If you find yourself trying to figure out how to do something, go back to a normal user shell until you are sure what needs to be done by root. ╖ Always be slow and deliberate running as root. Your actions could affect a lot of things. Think before you type! If you absolutely positively need to allow someone (hopefully very trusted) to have superuser access to your machine, there are a few tools that can help. Sudo allows users to use their password to access a limited set of commands as root. This would allow you to, for instance, let a user be able to eject and mount removable media on your linux box, but have no other root privileges. sudo also keeps a log of all sudo attempts and successes, allowing you to track down who used what command to do what. For this reason sudo works well even in places where a number of people have root access, but use sudo so you can keep track of changes made. 4.4. Trojan Horses A Trojan Horse is named after the fabled ploy in Homers great literary work. The idea is that you put up a program or binary that sounds great, and get other people to download it and run it as root. Then, you can compromise their system while they are not paying attention. While they think the binary they just pulled down does one thing (and it might very well), it also compromises their security. You should take care of what programs you install on your machine. redhat provides md5 checksums and pgp signed rpm files so you can verify you are installing the real thing. Other distributions have similar methods. You should never run any binary you don't have the source for or a well known binary as root! Few attackers are willing to release source code to public scrutiny. Although it can be complex, make sure you are getting the source for some program from it's real distribution site. If the program is going to run as root make sure either you or someone you trust has looked over the source and verified it. 4.5. Password Security & Encryption One of the most important security features used today are passwords. It is important for both you and all your users to have secure, unguessable passwords. Most of the more recent linux distributions include 'passwd' programs that not allow you to set a easily guessable password. Make sure your passwd program is up to date and has these features. In depth discussion of encryption is beyond the scope of this document , but a introduction is in order. Encryption is very usefull, possibly even nessessary in this day and age. There are all sorts of methods of encrypting data, each with their own flaws and drabacks. Some of the more common ones you should be aware of: unix password encryption: Most unicies (and linux is no exception) use the DES (Data Encryption Standard) to encrypt your passwords. This encrypted password is then stored in (typically) /etc/passwd (or less commonly) /etc/shadow. When you attempt to login, whatever you type in is encrypted again and compaired with the entry in the passwd file. If they match, it must be the same password and you are allowed access. DES is a one-way encryption. DES is know to be pretty weak in these days of fast computers. Brute force attacks, such as crack or John the ripper (see below) can often guess passwords unless your password is sufficently random. PAM modules (see below) allow you to use a diffrent encryption routine with your passwords (MD5 or the like). 4.5.1. PAM - Pluggable Authentication Modules Newer versions of the RedHat linux distribution ship with a thing called "PAM". PAM allows you to change on the fly your authentication methods and requirements. Without re-compiling any of your binaries. Configuration of PAM is beyond the scope of this document, take a look at the PAM web site for more information. http://www.kernel.org/pub/linux/libs/pam/index.html Just a few of the things you can do with PAM: ╖ Use a non DES encryption for your passwords. (Making them harder to brute force decode. ╖ Set resource limits on all your users so they can't perform denial of service attacks (number of processes, amount of memory, etc). ╖ Enable shadow passwords (see below) on the fly. ╖ allow specific users to login only at specific times from specific places. 4.5.2. Shadow Passwords. Shadow passwords are a means of keeping your encrypted password information secret from normal users. Normally this encrypted password is stored in your /etc/passwd file for all to read. They can then run password guesser programs on it and attempt to determine what it is. Shadow passwords save this information to a /etc/shadow file that only privileged users can read. In order to run shadow passwords you need to make sure all your utilities that need access to password information are recompiled to support it. PAM (above) also allows you to just plug in a shadow module and doesn't require re-compilation of executables. 4.5.3. Crack and John the Ripper If for some reason your passwd program is not enforcing non easily guessable passwords, you might want to run a password cracking program and make sure your users passwords are secure. Password cracking programs work on a simple idea. They try every word in the dictionary, and then variations on those words. They encrypt each one and check it against your encrypted password. If they get a match they are in. There are a number of programs out there...the two most notable of which are "Crack" and "John the Ripper" http://www.false.com/security/john/index.html . They will take up a lot of your cpu time, but you should be able to tell if an attacker could get in using them by running them first yourself and notifying users with weak passwords. Note that an attacker would have to use some other hole first in order to get your passwd (unix /etc/passwd) file, but these are more common than you might think. 4.6. Integrity Checking with Tripwire Another very good way to detect local (and also network) attacks on your system is to run an integrity checker like Tripwire. Tripwire runs a number of checksums on all your important binaries and config files and compares them against a database of former values. Thus, any changes in the files will be flagged. It's a good idea to install tripwire onto a floppy, and then physically set the write protect on the floppy. This way intruders can't tamper with tripwire itself or change the database. Once you have tripwire setup, it's a good idea to run it once a day or so and check to see if anything has changed. You can even add a crontab entry to run tripwire from your floppy every night and mail you the results in the morning. Something like: # set mailto MAILTO=kevin # run tripwire 15 05 * * * root /usr/local/adm/tcheck/tripwire will mail you a report each morning at 5:15am. Tripwire can be a godsend to detecting intruders before you would otherwise notice them. Since a lot of files change on the average system, you have to be careful what is cracker activity and what is your own doing. 4.7. CFS - Cryptographic File System and TCFS - transparent crypto¡ graphic File System. CFS is a way of encrypting an entire file system and allow users to store encrypted files on them. It uses a NFS server running on the local machine. rpms are avail at http://www.replay.com/redhat/ and more information on how it all works is at: ftp://ftp.research.att.com/dist/mab/ TCFS improves on CFS, adding more integration with the file system, so that it's transparent to any users using the file system that it's encrypted. more information at: http://edu-gw.dia.unisa.it/tcfs/ 4.8. X11, SVGA and display security. 4.8.1. X11 It's important for you to secure your graphical display to prevent attackers from doing things like: grabbing your passwords as you type them without you knowing it, reading documents or information you are reading on your screen, or even using a hole to gain superuser access. Running remote X applications over a network also can be fraught with peril, allowing sniffers to see all your interaction with the remote system. X has a number of access control mechanisms. The simplest of them is host based. You can use xhost to specify what hosts are allowed access to your display. This is not very secure at all. If someone has access to your machine they can xhost + their machine and get in easily. Also, if you have to allow access from an untrusted machine, anyone there can compromise your display. When using xdm (x display manager) to login, you get a much better access method: MIT-MAGIC-COOKIE-1. A 128bit cookie is generated and stored in your .Xauthorty file. If you need to allow a remote machine access to your display, you can use the xauth command and the information in your .Xauthority file to provide only that connection access. You can also use ssh (see ssh, above) to allow secure X connections. This has the advantage of also being transparent to the end user, and means that no un-encrypted data flows across the network. Take a look at the Xsecurity man page for more information on X security. The safe bet is to use xdm to login to your console and then use ssh to go to remote sites you wish to run X programs off of. 4.8.2. SVGA SVGAlib programs are typically suid root in order to access all your linux machines video hardware. This makes them very dangerous. If they crash, you typically need to reboot your machine to get a usable console back. Make sure any SVGA programs you are running are authentic, and can at least be somewhat trusted. Even better, don't run them at all. 4.8.3. GGI (Generic Graphics Interface project) The linux GGI project is trying to solve several of the problems with video interfaces on linux. GGI will move a small piece of the video code into the linux kernel, and then control access to the video system. This means GGI will be able to restore your console at any time to a known good state. They will also allow a secure attention key, so you can be sure that there is no Trojan horse login program running on your console. http://synergy.caltech.edu/~ggi/ 4.9. identd identd is a small program that typically runs out of your inetd. It keeps track of what user is running what tcp service, and then reports this to whoever requests it. Many people misunderstand the usefulness of identd, and so disable it or block all off site requests for it. identd is not there to help out remote sites. There is no way of knowing if the data you get from the remote identd is correct or not. There is no authentication in identd requests. Why would you want to run it then? Because it helps _you_ out, and is another data-point in tracking. If your identd is un compromised, then you know it's telling remote sites the user-name or uid of people using tcp services. If the admin at a remote site comes back to you and tells you user so and so was trying to hack into their site, you can easily take action against that user. If you are not running identd, you will have to look at lots and lots of logs, figure out who was on at the time, and in general take a lot more time to track down the user. The identd that ships with most distributions is more configurable than many people think. You can disable identd for specific users (they can make a .noident file), you can log all identd requests (I recommend it), you can even have identd return a uid instead of a user name or even NO-USER. 5. Network Security Network security is becoming more and more important as people spend more and more time connected. Compromising network security is often much easier than physical or local, and is much more common. There are a number of good tools to assist with network security, and more and more of them are shipping with linux distributions. 5.1. Packet Sniffers One of the most common ways intruders gain access to more systems on your network is by employing a packet sniffer on a already compromised host. This "sniffer" just listens on the Ethernet port for things like "Password" and "Login" and "su" in the packet stream and then logs the traffic after that. This way, attackers gain passwords for systems they are not even attempting to break into. Clear text passwords are very vulnerable to this attack. EXAMPLE: host A has been compromised. Attacker installs a sniffer. Sniffer picks up admin logging into host B from Host C. It gets the admins personal password as they login to B. Then, the admin does a 'su' to fix a problem. They now have the root password for Host B. Later the admin lets someone telnet from his account to host Z on another site. Now the attacker has a password/login on host Z. In this day and age, the attacker doesn't even need to compromise a system to do this, they could also bring a laptop or pc into a building and tap into your net. Using ssh or other encrypted password methods thwarts this attack. Things like APOP for pop accounts also prevents this attack. (Normal pop logins are very vulnerable to this, as is anything that sends clear text passwords over the wire.) 5.2. System services and tcp_wrappers As soon as you put your linux system on ANY network the first thing to look at is what services you need to offer. Services that you do not need to offer should be disabled so that you have one less thing to worry about and attackers have one less place to look for a hole. There are a number of ways to disable services under linux. You can look at your /etc/inetd.conf file and see what services are being offered by your inetd. Disable any that you do not need by commenting them out (# at the beginning of the line), and then sending your inetd process a SIGHUP. You can also remove (or comment out) services in your /etc/services file. This will mean that local clients will also be unable to find the service (ie, if you remove ftp, and try and ftp to a remote site from that machine it will fail with an unknown service message). It's usually not worth the trouble to remove services, since it provides no additional security. If a local person wanted to use ftp even tho you had commented it out, they would make their own client that use the common ftp port and would still work fine. If you know you are not going to use some particular package, you can also delete it entirely. rpm -e under the redhat distribution will erase an entire package. Under debian dpkg likely does the same thing. You should check your /etc/rc.d/rcN.d, where N is your systems run level and see if any of the servers started in that directory are not needed. Simply remove the unneeded script(s) and they will not be started on your next reboot. If you have BSD style rc files, you will want to check /etc/rc* for programs you don't need. Most linux distributions ship with tcp_wrappers "wrapping" all your tcp services. A tcp_wrapper (tcpd) is invoked from inetd instead of the real server. tcpd then checks the host that is requesting the service and either launches the program or denies access from that host. tcpd allows you to restrict access to your tcp services. You should make a /etc/hosts.allow and add in only those hosts that need to have access to your machines services. If you are a home dialup user, I would suggest you deny ALL. tcpd also logs failed attempts to access services, so this can give you an idea that you are under attack. If you add new services, you should always tcp wrapper them if they are tcp based. 5.3. SATAN , ISS, and other network scanners There are a number of different software packages out there that do port and service based scanning of machines or networks. SATAN and ISS are two of the more well known ones. This software connects to the target machine (or all the target machines on a network) on all the ports it can, and tries to determine what service is running there. Based on this information, you could find out the machine is vulnerable to a specific exploit on that server. SATAN (Security Administrators Tool for Analyzing Networks) is a port scanner with a web interface. It can be configured to do light, medium, or strong checks on a machine or a network of machines. It's a good idea to get SATAN and scan your machine or network, and fix the problems it finds. Make sure you get the copy of SATAN from sun-site or a reputable FTP or web site. There was a Trojan copy of SATAN that was distributed out on the net. http://www.trouble.org/~zen/satan/satan.html ISS (Internet Security Scanner) is another port based scanner. It is faster than Satan, and thus might be better for large networks. However, SATAN tends to provide more information. Detecting Port scans. There are some tools designed to alert you to probes by Satan and ISS and other scanning software, However liberal use of tcp_wrappers and making sure to look over your log files regularly, you should be able to notice such probes. Even on the lowest setting, Satan still leaves traces in the logs on a stock Redhat system. 5.4. pgp and public key cryptography pgp (pretty good privacy) is well supported on linux. versions 2.62 and 5.0 are known to work well. For a good primer on pgp and how to use it, take a look a the pgp FAQ. http://www.pgp.com/service/export/faq/55faq.cgi 5.5. ssh and stelnet ssh (secure shell) and stelnet are programs that allow you to login to remote systems and have a encrypted connection. Ssh will prevent host spoofing attacks (It expects a specific key back from a host it's connected to before), it does compression and X11 forwarding in addition to encrypting all your communications with the remote machines. This is very good to defeat packet sniffer attacks (The packet sniffer gets a bunch of encrypted packets). ssh is free for personal use, so I would recommend you install it and use it if you are at a personal site. http://www.cs.hut.fi/ssh/ Stelnet is a secure telnet replacement that does encryption over a telnet connection. 5.6. sendmail, qmail and MTA's. One of the most important services you can provide is a mail server. Unfortunately, it is also one of the most vulnerable to attack, simply due to the number of tasks it must perform and the privileges it typically needs. If you are using sendmail it is very important to keep up on current versions. Sendmail has a long long history of security exploits. Always make sure you are running the most recent version. http://www.sendmail.org If you are tired of upgrading your version of sendmail every week, you might consider switching over to qmail. qmail was designed with security in mind from the ground up. It's fast and stable and secure. http://www.qmail.org 5.7. Denial of service attacks. A Denial of service attack is one where the attacker tries to make some resource too busy to answer legitimate requests, or to deny legitimate users access to your machine. Denial of service attacks have increased greatly in recent years. Some of the more popular and recent ones are listed below. Note that new ones show up all the time, so this is just a few examples. Read the linux security lists for more current information. SYN flooding. SYN flooding is a network denial of service attack. It takes advantage of a "loophole" in the way TCP connections are created. The newer linux kernels (2.0.30 and up) have several configurable options to prevent SYN flood attacks from denying people access to your machine or services. CONFIG_SYN_COOKIES and CONFIG_RST_COOKIES. Rebuild your kernel with these options to reduce your susceptibility to SYN flood attacks. Pentium "F00F" bug. It was recently discovered that a series of assembly codes send to a genuine Intel Pentium processor would lock the machine up totally. This affects every machine with a Pentium processor (not clones, not Pentium Pro or PII), no matter what operating system it's running. Linux kernel 2.0.32 and up contain a work around for this bug, preventing it from locking your machine. If you are running on a pentium, you should upgrade now! Ping flooding. Ping flooding is a simple brute force denial of service attack. Your attacker send a "flood" of ICMP packets to your machine. If they are doing this from a host with better bandwidth than yours, your machine will be unable to send anything on the network. A variation on this attack "smurfing" sends ICMP packets to a host with _your_ machines return IP, allowing them to flood you less detectably. If you are under a ping flood attack, use a tool like tcpdump to determine where the packets are coming from (or appear to be coming from), then contact your provider with this information. Ping floods can most easily be stopped at the router level. 5.8. NFS (Network File System) security. NFS is a very widely used file sharing protocol. It allows servers running nfsd and mountd to "export" entire filesystems to other machines with nfs filesystem support builtin to their kernels (or some other client support if they are non linux machines). Mountd keeps track of mounted filesystems in /etc/mtab, and can display them with 'showmount'. Many sites use NFS to serve home directories to users, so that no matter what machine in the cluster they login to, they will have all their home files. There is some small amount of "security" allowed in exporting filesystems. You can make your nfsd map the remote root user (uid=0) to the nobody user, denying them total access to the files exported. However, since individual users have access to their own (or at least the same uid) files, the remote superuser can login or su to their account and have total access to their files. This is only a small hindrance to an attacker that has access to mount your remote filesystems. If you must use NFS, make sure you export to only those machines that you really need to export only. Never export your entire root directory, export only directories you need to export. See the NFS HOWTO for more information on NFS: NFS HOWTO 5.9. NIS (Network Information service) (formerly YP). Network Information service (formerly YP) is a means of distributing information to a group of machines. The NIS master holds the information tables and converts them into NIS map files. These maps are then served over the network, allowing NIS client machines to get login, password, home directory and shell information (all the information in a standard /etc/passwd file). This allows users to change their password once and have it take affect on all the machines in the NIS domain. NIS is not at all secure. It was never meant to be. It was meant to be handy and usefull. Anyone that can guess the name of your NIS domain (anywhere on the net) can get a copy of your passwd file, and use crack and john the ripper against your users passwords. Also, it is possible to spoof NIS and do all sorts of nasty tricks. If you must use NIS, make sure you are aware of the dangers. There is a much more secure replacement for NIS, called NIS+. Check out the NIS HOWTO for more information: http://sunsite.unc.edu/mdw/HOWTO/NIS-HOWTO.html 5.10. Firewalls Firewalls are a means of restricting what information is allowed into and out of your local network. Typically the firewall host is connected to the Internet and your local lan, and the only access from your lan to the Internet is through the firewall. This way the firewall can control what passes back and forth from the Internet and your lan. There are a number of types and methods of setting up firewalls. Linux machines make pretty good low cost firewalls. firewall code can be built right into 2.0 and higher kernels. The ipfwadm user space tool allows you to change what types of network traffic you allow on the fly. You can also log particular types of network traffic. Firewalls are a very usefull and important technique in securing your network. It is important to realize that you should never think that because you have a firewall, you don't need to secure the machines behind it. This is a fatal mistake. Check out the very good Firewall- HOWTO at your latest sun-site archive for more information on firewalls and linux. http://sunsite.unc.edu/mdw/HOWTO/Firewall- HOWTO.html 6. What to do during and after a breakin So you have followed some of the advice here (or elsewhere) and have detected a breakin? The first thing to do is to remain calm. Hasty actions can cause more harm than the attacker would have. 6.1. Security Compromise under way. Spotting a security compromise under way can be a tense undertaking. How you react can have large consequences. If the compromise you are seeing is a physical one, odds are you have spotted someone who has broken into your home, office or lab. You should notify your local authorities. In a lab setting you might have spotted someone trying to open a case or reboot a machine. Depending on your authority and procedures, you might ask them to stop, or contact your local security people. If you have detected a local user trying to compromise your security, the first thing to do is confirm they are in fact who you think they are. Check the site they are logging in from. Is it the site they are normally in from? no? Then use a non electronic means of getting in touch. For instance call them on the phone or walk over to their office/house and talk to them. If they agree that they are on, you can ask them to explain what they were doing or tell them to cease doing it. If they are not on, and have no idea what you are talking about, odds are this incident requires further investigation. Look into such incidents , and have lots of information before making any accusations. If you have detected a network compromise, the first thing to do (if you are able) is to disconnect your network. If they are connected via modem, unplug the modem cable, if they are connected via ethernet, unplug the ethernet cable. This will prevent them from doing any further damage, and they will probably see it as a network problem rather than detection. If you are unable to disconnect the network (if you have a busy site, or you do not have physical control of your machines), the next best step is to use something like tcp_wrappers or ipfwadm to deny access from the intruders site. If you can't deny all people from the same site as the intruder, locking the users account will have to do. Note that locking an account is not an easy thing. You have to keep in mind .rhosts files, FTP access, and a host of backdoors). After you have done one of the above (disconnected network, denied access from their site, and/or disabled their account), you need to kill all their user processes and log them off. You should monitor your site well for the next few minutes, as the attacker will try and get back in. Perhaps using a different account, and/or from a different network address. 6.2. Security Compromise has already happened. So you have either detected a compromise that has already happened or you have detected it and locked (hopefully) the offending attacker out of your system. Now what? 6.2.1. Closing the Hole If you are able to determine what means the attacker used to get into your system, you should try and close that hole. For instance, perhaps you see several FTP entries just before the user logged in. Disable the FTP service and check and see if there is an updated version or any of the lists know of a fix. Check all your log files, and make a visit to your security lists and pages and see if there are any new common exploits you can fix. If you don't lock the attacker out, they will likely be back. Not just back on your machine, but back somewhere on your lan. If they were running a packet sniffer, odds are good they have access to other local machines. 6.2.2. Assessing the Damage The first thing is to assess the damage. What has been compromised? If you are running an Integrity Checker like Tripwire you can make a tripwire run and it should tell you. If not, you will have to look around at all your important data. Since linux systems are getting easier and easier to install, you might consider saving off your config files and then wiping your disk(s) and reinstalling, then restoring your user files from backups and your config files. This will insure that you have a new clean system. 6.2.3. Backups, Backups, Backups! Having regular backups is a godsend for security matters. If your system is compromised, you can restore the data you need from backups. Of course some data is valuable to the attacker to, and they will not only destroy it, they will steal it and have their own copies, but at least you will still have the data. You should check several backups back into the past before restoring a file that has been tampered with. The intruder could have compromised your files long ago, and you could have made many successful backups of the compromised file!!! Of course, there are also a raft of security concerns with backups. Make sure you are storing them in a secure place. Know who has access to them. (If an attacker can get your backups, they can have access to all your data without you ever knowing it.) 6.2.4. Tracking down the intruder. Ok, you have locked the intruder out, and recovered your system, but you're not quite done yet. While it is unlikely that most intruders will ever be caught, you should report the attack. You should report the attack to the admin contact at the site where the attacker attacked your system. You can look up this contact with "whois" or the internic database. You might send them an email with all applicable log entries and dates and times. If you spotted anything else distinctive about your intruder, you might mention that too. After sending the email, you should (if you are so inclined) follow up with a phone call. If that admin in turn spots your attacker, they might be able to talk to the admin of the site where they are coming from and so on. Good hackers often use many intermediate systems. Some (or many) of which may not even know they have been compromised. Trying to track a cracker back to their home system can be difficult. Being polite to the admins you talk to can go a long way to getting help from them. You should also notify any security organizations you are a part of (cert or similar). 7. Security sources There are a LOT of good sites out there for unix security in general and linux security specifically. It's very important to subscribe to one (or more) of the security mailing lists and keep current on security fixes. Most of these lists are very low volume, and very informative. 7.1. FTP sites CERT is the Computer Emergency Response Team. They often send out alerts of current attacks and fixes. cert.org Replay has archives of many security programs. Since they are outside the US, they don't need to obey any silly US crypto restrictions. replay.com Matt Blaze is the author of CFS and a great security advocate. Matt Blaze's stuff Sorosis is the home of the linux PAM site. They have lots of modules and information on PAM. Linux PAM ftp site tue.nl is a great security ftp site in the Netherlands. ftp.win.tue.nl 7.2. The Hacker FAQ is a FAQ about hackers: The Hacker FAQ web sites The COAST archive has a large number of unix security programs and information: COAST Rootshell.com is a great site for seeing what exploits are currently being used by crackers: rootshell.com exploits BUGTRAQ puts out advisories on security issues: BUGTRAQ archives CERT, the Computer Emergency Response Team, puts out advisories on common attacks on unix platforms: CERT home Dan Farmer is the author of SATAN and many other security tools, his home site has some interesting security survey information as well as security tools: Dan Farmers trouble.org The linux security WWW is a good site for linux security information: Linux Security WWW Reptile has lots of good linux security information on his site: Reptiles Linux Security Page Infilsec has a vulnerability engine that can tell you what vunerabilities affect a specific platform: Infilsec vunerability engine CIAC sends out periodic security bulitins on common exploits: CIAC bulitins 7.3. mailing lists Bugtraq: To subscribe to bugtraq, send mail to listserv@netspace.org containing the message body subscribe bugtraq. (see links above for archives). CIAC: Send e-mail to: majordomo@tholia.llnl.gov In the BODY (not subject) of the message put (either or both): subscribe ciac-bulletin 7.4. Books - printed reading material. There are a number of good security books out there. This section lists a few of them. In addition to the security specify books, security is covered in a number of other books on system administration. Building Internet Firewalls By D. Brent Chapman & Elizabeth D. Zwicky 1st Edition September 1995 ISBN: 1-56592-124-0 Practical UNIX & Internet Security, 2nd Edition By Simson Garfinkel & Gene Spafford 2nd Edition April 1996 ISBN: 1-56592-148-8 Computer Security Basics By Deborah Russell & G.T. Gangemi, Sr. 1st Edition July 1991 ISBN: 0-937175-71-4 Linux Network Administrator's Guide By Olaf Kirch 1st Edition January 1995 ISBN: 1-56592-087-2 PGP: Pretty Good Privacy By Simson Garfinkel 1st Edition December 1994 ISBN: 1-56592-098-8 Computer Crime A Crimefighter's Handbook By David Icove, Karl Seger & William VonStorch (Consulting Editor Eugene H. Spafford) 1st Edition August 1995 ISBN: 1-56592-086-4 8. Conclusion By subscribing to the security alert mailing lists, and keeping current, you can do a lot towards securing your machine. If you pay attention to your log files and run something like tripwire regularly, you can do even more. A reasonable level of computer security is not difficult to maintain on a home machine. More effort is required on business machines, but linux can indeed be a secure platform. Due to the nature of linux development, security fixes often come out much faster than they do on commercial operating systems, making linux an ideal platform when security is a requirement. 9. Thanks to Information here is collected from many sources. Thanks to the following that either indirectly or directly have contributed: Rob Riggs <rob@DevilsThumb.com> S. Coffin <scoffin@netcom.com> Viktor Przebinda <viktor@CRYSTAL.MATH.ou.edu> Roelof Osinga <roelof@eboa.com> Kyle Hasselbacher <kyle@carefree.quux.soltec.net> "David S. Jackson" <dsj@dsj.net>